Throughout the software development lifecycle, items (e.g., requirements, implementation work items, and test cases) may be defined to help guide the software development efforts to a meaningful end product. However, as work is done at each stage of the software development process, the items may evolve from their initial state. For instance, relationships between each item (e.g., a test case which validates a requirement) may become invalid as the requirement evolves.
Furthermore, the items in question may be contained by separate solutions. For example, one application may contain the requirements, another application may contain the test cases, and yet another application may contain the implementation work items. It may be possible for these applications each to provide the ability to allow linking from their contained artifact types to artifacts contained by each other application; however, each application may be responsible for tracking changes in its own contained resources, and may be unaware of changes outside of this scope.
Additionally, managing change between many items (e.g., documents) from several users may be a difficult and time consuming process. By using “suspicion flags” to mark documents as suspect across, e.g., traceability links between the documents, a user may find it easier to see the impact of such changes. However, situations may arise where a change may cause an artifact on the other end of a traceability link to become suspect, which may result in suspicion flags being raised when the associated change may be minor or not important.